home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
QRZ! Ham Radio 4
/
QRZ Ham Radio Callsign Database - Volume 4.iso
/
digests
/
digital
/
940182.txt
< prev
next >
Wrap
Text File
|
1994-11-13
|
23KB
|
534 lines
Date: Mon, 6 Jun 94 04:30:19 PDT
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V94 #182
To: Ham-Digital
Ham-Digital Digest Mon, 6 Jun 94 Volume 94 : Issue 182
Today's Topics:
An open note to Gary Coffman, KE4ZV (6 msgs)
Ethernet address Directory?
GRINOS AND ETHERNET
Internet <-> Packet gateway (2 msgs)
Motorola GPS engine purchase information
NPFPMS update version 2.20A available
Vester SSTV board
Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: 5 Jun 1994 20:31:14 GMT
From: ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!wupost!crcnis1.unl.edu!ace.mid.net!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!icaen!drenze@network.ucsd.
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu
davidj@rahul.net (David Josephson) writes:
>Gary's letter isn't here, but Doug's open letter is a fine start. And
>we have all read replies about one technical angle or another being the
>seed of our discontent. But have we ever thought about applications for
>packet radio? Excuse me, but what is this thing for?
If Gary will give his permission, I can post a copy of his letter. It's
in the archives somewhere on our PBBS here.
>Pedro Colla wrote a long article, pointing out what we have here: it is
>a low bandwidth, anarchic, highly resilient network that will work,
>eventually. Practical throughput, once there are more than two stations
>involved, is a few tens or hundreds of baud. It is a thin network. Why
>don't we give up on thinking of it as a ham Ethernet and start working
>on more applications where this sort of information pipe will do some good?
I agree--I wasn't necessarily suggesting that we should create an alternate
Internet. The I-net examples I used were merely suggestions. I do think,
though, that a TCP/IP network wouldn't be bad. Ie, e-mail could be handled
by presently-existing SMTP applications. We could use things like FTPMail
for file/data transfer. We could replace the existing haphazard system
of bulletins with something using existing Usenet protocols, mail routing
would be expedited.
It would also be easier to support things such as (I think)
Gary Coffman suggested--ie, a simple FORTH-like language to carry out
remote tasks. I envision something like:
: MAIN
"STTNG" dbselect ( selects the database to be searched )
"worf" "riker" "troi" and and ( selects keywords to search for )
"picard" "riker" or not and ( selects keywords to exclude )
SEARCH ( executes the database search )
;
which could then be compiled into a tokenized string that would be uploaded
to the interpreter and executed. If it worked, it'd self-delete and mail
the results back to the originator, else it would be passed onto the next
computer in the chain.
I've actually sort of spec'ed out something along these lines. It
wouldn't necessarily have to support recursion in the initial stages, and
could be written with a relatively simple YACC grammar, methinks. I think
that the TinyMUCK code which supports the MUF programming language would be
a good example of how something like this could work.
Ack. I guess I've gotten off my original track. But anyway. This is,
BTW, something which could be adapted to the Internet with fantastic
results. Imagine being able to mail such a search program off to an
archie server, or a network of WAIS servers.
Food for thought.
73 - doug
>73
>David WA6NMF
>--
>David Josephson / Josephson Engineering / San Jose CA / david@josephson.com
--
Doug Renze, N0YVW * drenze@isca.uiowa.edu * N0YVW @ W0IUQ.ia.usa.na
DRenze@aol.com ** drenze@chop.isca.uiowa.edu
------------------------------
Date: Sun, 5 Jun 1994 11:44:09 GMT
From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!pipex!uknet!cix.compulink.co.uk!packman@network.ucsd.edu
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu
> Hmmm...must ask my local Satgate operator about getting (another) > look
> at the programs. Sounds like it could be an interesting
> experiment...even more interesting if the source code was available.
Just asked him and he says that whilst PB/PG (the user progs) are readily
available, he's never seen a Pacsat simulator program around. He reckoned
it might not be available due to 'commercial' interests in the satellite
program :(
Chris - G6FCI Packet : G6FCI @ GB7FCI.#16.GBR.EU
Internet : packman@cix.compulink.co.uk
------------------------------
Date: 6 Jun 1994 04:58:02 GMT
From: nothing.ucsd.edu!brian@network.ucsd.edu
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu
packman@cix.compulink.co.uk ("Chris Mcmahon") writes:
>For Mr Joe User who is a black box operator that buys a TNC off the shelf
I do not sympathise with people who refuse to learn the state of the
art. They have chosen not to keep up; if they therefore can't do some
of the more advanced things, that is the result of THEIR DECISION.
A falsely-perceived need for backwards-compatability has held back more
progress than all the world's Luddites combined.
- Brian
------------------------------
Date: 6 Jun 1994 04:54:26 GMT
From: nothing.ucsd.edu!brian@network.ucsd.edu
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu
WB6YMH and I proposed the news broadcast scheme some years ago; it's
been tossed around a number of times since, but no one has gotten around
to writing the actual client (there is a sender). Certainly the various
clients intended for use with the PACSATS could (and do) work, but a
more purpose-built client would be better.
I envision that the news would be broadcast CONTINUOUSLY in round-robin
fashion - no need for the transmitter to ever unkey. New articles would
be added and old ones expired from the list over time.
User stations would run a background process (a "TSR" in MS-DOG parlance)
that would suck in the articles as they're broadcast (selectively or not
as the user specified), squirrel them away on disk, and update an index.
Since the user station never has to transmit - fills happen automatically
from the repeated broadcasts and error-correction coding could help -
there's no issue of unattended transmitter operation - it's receive only!
When the user stopped playing space blaster, gets back from the office,
or whatever, he'd be able to fire up a news reader and read the articles
that had appeared. Read them FAST, off local disk, not over the air.
I know that the idea of a continuous bulletin transmission doesn't sit
well with a lot of hams, but in the USA it's legal and it's clearly efficient.
Some day I or someone else will write the client and then it'll be time
to clank on the sender. You know, a single 10-watt transmitter on a
single 2m frequency on one mountaintop here in SoCal could cover
thousands of square miles and serve thousands of hams all at once.
- Brian
------------------------------
Date: Sat, 4 Jun 1994 14:50:49 +0000
From: ihnp4.ucsd.edu!agate!doc.ic.ac.uk!uknet!demon!djwhome.demon.co.uk!david@network.ucsd.edu
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu
In article <1994Jun2.105141.15184@cnsvax.uwec.edu> whitemp@hemp (Mike White) writes:
>Actually, the solution, as I see it, is to modify the 8250slip.com (or
>whatever they call it nowadays) so that it operates with KISS rather
>than slip. KA9Q does a fine job, true, but it is an application and not
It's not quite as simple as this. Amateur packet is a broadcast medium and
needs an address resolution protocol. SLIP is a point to point protocol and
doesn't use an address resolution protocol. A lot of TCP/IP software
actually doesn't support SLIP class drivers, so there are SLIP drivers which
spoof ARP to keep the stack happy. Also packet drivers assume that the
higher software provides MAC level header information. To run with normal
stacks, you have to run ARP within the packet driver and map ethernet or
token ring addresses into callsigns within the driver. (I think you also
have to handle parts of the AX.25 protocol, if you are using KISS.)
I seem to remember that there is an AX.25 class for packet drivers, but that
would only work with AX.25 aware stacks (will KA9Q work with such drivers?).
All this processing is going to make a KISS packet driver big and non-trivial
to write, but not impossible. It may have been done, but I would have
expected it to have been mentioned in this thread by now, if that were the
case.
--
David Woolley, London, England david@djwhome.demon.co.uk
Demon is an IP/SMTP/NNTP Provider. *.demon hosts are independently managed.
------------------------------
Date: Sun, 05 Jun 1994 19:50:00 PST
From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!mala.bc.ca!epaus!ham!emd@network.ucsd.edu
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu
davidj@rahul.net (David Josephson) writes:
>ARESPACK from WN6I tracks who/where/what during a disaster. APRS plots
>locations of stations, DF headings, station status, etc on a map from
>information transmitted on packet. And the DX cluster is a perfect
>example of how we can use this mode to make things nicer.
>
ARESPACK sounds like just the thing I could use here as ESS Comms
director. Where can I find it?
Tnx, Bob.
emd@ham.island.net (Robert Smits Ladysmith BC)
------------------------------
Date: 5 Jun 1994 10:48:31 GMT
From: ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!EU.net!Austria.EU.net!newsfeed.ACO.net!nippur.irb.hr!thphys!sinisa@network.ucsd.edu
Subject: Ethernet address Directory?
To: ham-digital@ucsd.edu
In <BAT.94Jun3070029@gdstech.GRUMMAN.COM> bat@gdstech.GRUMMAN.COM (Pat Masterson) writes:
> Each vendor has a whole BLOCK of ethernet addresses. So, each card
>they make can have a different address. These blocks are listed in
>an RFC, but I don't remember which one. And, for new ones, or
>those that don't seem to be listed, you can call the IEEE and ask
>them. They might not tell you who the vendor is, but they can have
Also look on FTP.LCS.MIT.Edu , file pub/map/EtherNet-codes
(via anonftp, of course).
Great!
>a vendor rep call you back if you need to identify some wayward
>ethernet address.
>--
>*-----------------------------------------------------------*
>* Pat Masterson D12-25 | KE2LJ@KC2FD *
>* Grumman Data Systems | 516-346-6316. *
>* Bethpage, NY 11746 | bat@gdstech.grumman.com *
Sinisa
--
-----------------------------------------------------------------------------
! Sinisa Novosel, Institut Rugjer Boskovic, dep. FIZIKA; Croatia,Zagreb !
! sinisa@thphys.irb.hr !
-----------------------------------------------------------------------------
------------------------------
Date: Sun, 5 Jun 94 08:54:28 GMT
From: ihnp4.ucsd.edu!usc!math.ohio-state.edu!caen!news.umass.edu!nic.umass.edu!usenet@network.ucsd.edu
Subject: GRINOS AND ETHERNET
To: ham-digital@ucsd.edu
In Article <"940602.14:00:42*.G=KRISTOFF.S=BONNE.OU=PIRESSYS.O=BELGACOM.PRMD=RTTIPC.ADMD=RTT.C=BE."@MHS>
kbonne@nx.rtt.rtt.BE (Kristoff BONNE) writes:
..
>I've put NOS on a PC at my qrl to do some tests on the LAN.
..
>When I send/receive 'a lot' of data ('a lot' being some hundred bytes), the
>session hangs. (the rest of NOS still works OK?)
I don't have an answer, but have seen the problem with a slightly different
configuration (386, and a different packet driver). It occurs when I connect
via ethernet to a VAX or a Sun, both of which are set up to service large
numbers of users. The VAX session usually hangs up before it gets through
the messages of the day. The Sun will crash when I do an ls -l command
on a moderately big directory.
I inquired on other groups about this and was given a suggestion that the
telnet escape character default for NOS was the problem, but in fact it made
no difference.
I suspect the problem may be that NOS does dynamic memory allocation and
just can't do it fast enough to handle a large amount of data coming in fast,
i.e., at ethernet speeds. Try using the "mem stat" command after this happens.
I think a solution might be to recompile a NOS with less stuff in it, to use
less memory. But I've never tried this.
The problem is not inherent in the ethernet interface per se, I can connect
NOS via ethernet to another NOS box, to a Minix box, or to a couple of Linux
systems. But these systems don't output as much data as the VAX or Sun.
Albert S. Woodhull
Hampshire College, Amherst, MA, USA
awoodhull@hamp.hampshire.edu
------------------------------
Date: 5 Jun 1994 20:50:34 GMT
From: bloom-beacon.mit.edu!senator-bedfellow.mit.edu!mit.edu!maui@uunet.uu.net
Subject: Internet <-> Packet gateway
To: ham-digital@ucsd.edu
Hi there:
This question is coming from someone who is Internet experienced but has
very little HAM experience. I am looking for a gateway to communciate
with someone who has an address on a Packet BBS in AZ. I know gateways
between the Internet and Packet exist. Can someone tell me where one is
and how to use it? Please e-mail me the answer to this question since I
don't really read this newsgroup.
- Thanks -
___
(|)ark Uhrmacher
maui@mit.edu
------------------------------
Date: 06 Jun 1994 01:35:17 GMT
From: yale.edu!noc.near.net!chaos.dac.neu.edu!chaos.dac!wy1z@yale.arpa
Subject: Internet <-> Packet gateway
To: ham-digital@ucsd.edu
In article <MAUI.94Jun5165034@xv.mit.edu> maui@mit.edu (Mark A Uhrmacher) writes:
Path: chaos.dac.neu.edu!grapevine.lcs.mit.edu!olivea!decwrl!ames!agate!howland.reston.ans.net!pipex!sunic!trane.uninett.no!eunet.no!nuug!EU.net!uunet!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!mit.edu!maui
From: maui@mit.edu (Mark A Uhrmacher)
Newsgroups: rec.radio.amateur.digital.misc
Date: 5 Jun 1994 20:50:34 GMT
Organization: Massachusetts Institute of Technology
Lines: 13
Distribution: world
NNTP-Posting-Host: xv.mit.edu
Hi there:
This question is coming from someone who is Internet experienced but has
very little HAM experience. I am looking for a gateway to communciate
with someone who has an address on a Packet BBS in AZ. I know gateways
between the Internet and Packet exist. Can someone tell me where one is
and how to use it? Please e-mail me the answer to this question since I
don't really read this newsgroup.
- Thanks -
___
(|)ark Uhrmacher
maui@mit.edu
Check out: oak.oakland.edu:/pub/hamradio/docs/packet-internet
There is gateway info there.
If you need any help, please let me know.
Scott
--
===============================================================================
| Scott Ehrlich Amateur Radio: wy1z AMPRnet: wy1z@wa1phy.ampr.org |
| Internet: wy1z@neu.edu BITnet: wy1z@NUHUB AX.25: wy1z@wa1phy.ma.usa.na |
|-----------------------------------------------------------------------------|
| Maintainer of the Boston Amateur Radio Club hamradio FTP area on |
| oak.oakland.edu - /pub/hamradio |
===============================================================================
------------------------------
Date: Sat, 4 Jun 1994 14:30:58 GMT
From: ihnp4.ucsd.edu!usc!cs.utexas.edu!utnut!torn!uunet.ca!uunet.ca!geac!torsqnt!problem!vigard!mdf@network.ucsd.edu
Subject: Motorola GPS engine purchase information
To: ham-digital@ucsd.edu
alanb@sr.hp.com (Alan Bloom) writes:
>Marc T. Kaufman (kaufman@Xenon.Stanford.EDU) wrote:
>: ... the GPS measured position changes with time (dithers).
>
>What is the time constant of the GPS Selective Availability dithering?
>Does it change on the order of hours, minutes, seconds or even faster?
minutes, i believe. the marine DGPS systems being setup by the US and
Canadian coast guards broadcast pseudo-range corrections, at 50 bits
per second, on top of existing navigation beacons in the 300-500kHz area.
>AL N1AL
--
Matthew Francey mdf@vigard.mef.org ve3rqx@io.org
"live before you die" GPS(NAD27): N43o34.210' W079o34.563' +0093m
------------------------------
Date: Sun, 5 Jun 1994 11:50:58 +0000
From: ihnp4.ucsd.edu!swrinde!pipex!demon!g8dzh.demon.co.uk!John@network.ucsd.edu
Subject: NPFPMS update version 2.20A available
To: ham-digital@ucsd.edu
Version 2.20a of the G8NPF Personal Message System (NPFPMS) is now available
as a self-exploding file 'NPF220A.EXE'. NPFPMS is designed to be used with
G8BPQ node software (version 4.05 or greater) on PC-AT class (286 and higher)
machines. New functions since the last Internet release 2.16d include:-
* Support for FBB Unproto broadcasts to maintain message lists. Messages read
from FBB BBS's by the AutoRead function can use compressed file format.
* Archive Message facility added.
* Virtual (ram) disk (or a different hard disk) support for temporary files.
* Extensions added to YAPP transfer protocol.
Crash recovery. Resume an aborted file download.
YappC checksum mode. (as used by FBB)
Plus many other improvements. NPF220A.EXE and information file NPF220A.TXT can
be ftp'ed from :
ftp.demon.co.uk [158.152.1.69] /pub/ham
ftp.funet.fi [128.214.248.6] /pub/ham/packet/misc
--
John Ray | Internet: John@g8dzh.demon.co.uk
Loughton | CI$ 100041,305
Essex | AMPRnet: g8dzh@gb7ine.ampr.org [44.131.182.1]
England | AX25: G8DZH@GB7HSN.#32.GBR.EU
------------------------------
Date: Mon, 6 Jun 1994 01:13:19 GMT
From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!ub!freenet.buffalo.edu!aa450@network.ucsd.edu
Subject: Vester SSTV board
To: ham-digital@ucsd.edu
In a previous article, jeff.smith@n9csa.com (Jeff Smith) says:
>Hey guys,
>Can anybody make a Vester SSTV board ( QST Jan. 1994) for me? I will pay
>you $$. I am a new ham awaiting my ticket but I have no electrical
>knowledge. Please help!!! Leave me a message.
>Thanks and 73's, Jeff
>
FAR has that board for sale. See their add for address. It's < $5.
But... the circuit is so simple you can use a scrap of perfboard just
as well. I bumped into Ben Vester at Dayton and he pulled his out of
a pocket to show me, and.... it was a 2" square of perfboard.
Good luck, Kurt
--
------------------------------
Date: Mon, 6 Jun 94 09:09:08 GMT
From: ihnp4.ucsd.edu!swrinde!pipex!uknet!uos-ee!ee.surrey.ac.uk!M.Willis@network.ucsd.edu
To: ham-digital@ucsd.edu
References <1994Jun3.150706.7300@ke4zv.atl.ga.us>, <CqvMru.A3D@cix.compulink.co.uk>, <2suacq$fvt@network.ucsd.edu>π
Subject : Re: An open note to Gary Coffman, KE4ZV
In article <2suacq$fvt@network.ucsd.edu>, brian@nothing.ucsd.edu (Brian Kantor) writes:
|> packman@cix.compulink.co.uk ("Chris Mcmahon") writes:
|> >For Mr Joe User who is a black box operator that buys a TNC off the shelf
|>
|> I do not sympathise with people who refuse to learn the state of the
|> art. They have chosen not to keep up; if they therefore can't do some
|> of the more advanced things, that is the result of THEIR DECISION.
|>
|> A falsely-perceived need for backwards-compatability has held back more
|> progress than all the world's Luddites combined.
|> - Brian
And a falsely-perceived need for change has held back progress even more. You can't
just write off a worlds worth of equipment because it is now possible to go twice
as quickly.
Regarding your lack of sympathy, are you unsympathetic to the unwilling or the
incapable?
How many times does it need to be proved that the average person does not
have the intellect to keep up with the state of the art? Perhaps we should take
away the licences of all those black boxers who can not pass a new, suitably
difficult, technical exam?
The reason people refuse to learn the state of the art is that the majority of
those who are at that level are either incapable of teaching others or make things
so difficult to understand that no-one else has a chance. For example, TCP/IP.
There are a lot of developers out there who have written some very clever software.
In the main the manuals are terrible. They are concise, exact and tell the beginner
nothing. Acronyms are used all over the place, yet no list of acronyms is provided
so you need to remember each one. Software that is not easy to use is bad software.
If you require a large amount of technical insight to use an item, then it is badly
designed.
When it is so hard to get started, no wonder those with less ability give up. I
agree that we need to get rid of the CB mentality type of black box operator who
knows nothing and is able, but not prepared, to learn.
Mike
------------------------------
Date: Mon, 6 Jun 1994 00:58:09 GMT
From: news.Hawaii.Edu!uhunix3.uhcc.Hawaii.Edu!jherman@ames.arpa
To: ham-digital@ucsd.edu
References <2skvhe$qov@Times.Stanford.EDU>, <CqsAx8.155@srgenprp.sr.hp.com>, <1994Jun4.143058.18107@vigard.mef.org>
Subject : Re: Motorola GPS engine purchase information
In article <1994Jun4.143058.18107@vigard.mef.org> mdf@vigard.mef.org (Matthew Francey) writes:
>
>minutes, i believe. the marine DGPS systems being setup by the US and
>Canadian coast guards broadcast pseudo-range corrections, at 50 bits
>per second, on top of existing navigation beacons in the 300-500kHz area.
That wouldn't be very helpful to the ham community - those beacons
you speak of (285-325 kc is the maritime beacon band; the aeronautical
beacons operate from 200 to 415 kc) only have a range from 5 to 50 miles.
Jeff NH6IL
------------------------------
End of Ham-Digital Digest V94 #182
******************************